home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9322 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.3 KB  |  79 lines
  1. Path: cs.tu-berlin.de!news
  2. From: Roman Lechtchinsky <wolfro@cs.tu-berlin.de>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Saving a C++ object
  5. Date: 1 Mar 1996 00:41:27 GMT
  6. Organization: Technical University of Berlin, Germany
  7. Message-ID: <4h5h3n$82h@news.cs.tu-berlin.de>
  8. NNTP-Posting-Host: 130.149.17.223
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset=iso-8859-1
  11. Content-Transfer-Encoding: 8bit
  12.  
  13. Ben Jefferys <brj@doc.ic.ac.uk> writes:
  14. > When I save a C++ object just using:
  15. > 
  16. > ----------------------------
  17. > class ovoid{
  18. > /* etc. */
  19. > }
  20. > 
  21. > ovoid square
  22. > 
  23. > file.write((unsigned char *) &square, sizeof(ovoid))
  24. > ----------------------------
  25. > 
  26. > What *exactly* is saved? I'm finding that every time I recompile
  27. > an application when I've added some new code, trying to load
  28. > an object saved in this way with an old version of the application
  29. > crashes it, even if the class of the object in question hasn't
  30. > changed. I presume there are some pointers or something which are
  31. > changing when I add new chunks of code. What can I do to avoid this?
  32. > 
  33. > (ovoid doesn't containg any explicit pointers which are not reset when
  34. > reloading - ie. I'm not trying to use old pointers which have
  35. > been saved - not to my knowledge anyway)
  36. >
  37.  
  38. I can only guess, but if you are using virtual functions in ovoid the
  39. problem can be explained easily. Your compiler ( every compiler, actually )
  40. stores a pointer to the virtual function table within the object. This 
  41. table contains the addresses of the virtual functions that are to be called
  42. for this object. When you recompile your program the location of these
  43. functions in the image is changed. Then, when you read back your object
  44. the pointer to the table is overwritten and the next time a virtual function
  45. is called the application crashes. The best solution I've found is 
  46. - assuming you don't want to implement explicit save/load functions -
  47. to define a struct like
  48.  
  49. struct _ovoid
  50. {
  51. the data you want to save
  52. };
  53.  
  54. and then derive ovoid from this struct:
  55.  
  56. class ovoid : public _ovoid
  57. {
  58. the data you don't want to save
  59.  
  60. member functions
  61. };
  62.  
  63. Then you can the object with 
  64. file.write((unsigned char *) (_ovoid *)&square, sizeof(_ovoid)).
  65.  
  66.  
  67. > 
  68. > Also, is there anything dodgy about saving a class from within itself, 
  69. > using:
  70. > 
  71. > file.write((unsigned char *) &this, sizeof(ovoid))
  72. > 
  73.  
  74. No way. Just go on, everybody does it like that.
  75.  
  76. Bye
  77.  
  78. Roman
  79.